home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000028_owner-urn-ietf _Tue Nov 5 04:48:36 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB

  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA16345 for urn-ietf-out; Tue, 5 Nov 1996 04:48:36 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA16340 for <urn-ietf@services.bunyip.com>; Tue, 5 Nov 1996 04:48:33 -0500
  3. Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA00389  (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 04:48:29 -0500
  5. Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42])
  6.         by nic.cafax.se (8.8.2/8.8.2) with SMTP
  7.         id KAA06251;
  8.         Tue, 5 Nov 1996 10:46:18 +0100 (MET)
  9. Date: Tue, 5 Nov 1996 10:46:17 +0100 (MET)
  10. From: Patrik Faltstrom <paf@swip.net>
  11. X-Sender: paf@nic.cafax.se
  12. To: Martin J Duerst <mduerst@ifi.unizh.ch>
  13. Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com
  14. Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax          draft)
  15. In-Reply-To: <"josef.ifi..324:04.10.96.10.50.51"@ifi.unizh.ch>
  16. Message-Id: <Pine.BSI.3.91.961105104008.6238B-100000@nic.cafax.se>
  17. Mime-Version: 1.0
  18. Content-Type: TEXT/PLAIN; charset=US-ASCII
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Patrik Faltstrom <paf@swip.net>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. On Mon, 4 Nov 1996, Martin J Duerst wrote:
  25.  
  26. > - Specify that protocols may only reserve 1-octet UTF-8 characters
  27. >     (i.e. ASCII).
  28.  
  29. This is kind of stupid from my point of view. We do not win
  30. anything by doing this, do we?
  31.  
  32. > - Specify that protocols have to define their own escaping mechanisms
  33. >     for things beyond ASCII.
  34.  
  35. This is better, much better. We say that native URNs are 8-bit
  36. following the UTF-8 specification and that the protocol have
  37. to come up with its own escaping mechanism.
  38.  
  39. Just because the US-ASCII characters are represented by themselves
  40. in an UTF-8 string, and these octets can not occur in any other
  41. UTF-8 sequence, I can not see that we have problems with the
  42. normal "dangerous" characters in for example a URL, i.e. space,
  43. percent, plus etc. A space can only occur in a UTF-8 string as
  44. a space, representing a space, so it has to be %encoded.
  45.  
  46. It should because of this be quite easy :-) for each protocol to
  47. check what happens when a UTF-8 string is passed. My experience is
  48. that UTF-8 strings behaves like ISO-8859-1 strings, if you don't
  49. start inserting linebreaks, counting characters etc.
  50.  
  51.    Patrik
  52.